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Description 

Background of the Invention 
Field of the Invention 

This invention relates to a volume management 
system wherein the system using the volume manage- 
ment driver may also access a storage device directly 
without conflicting with the volume management sys- 
tem. 

More particularly, the invention relates to augment- 
ing the volume management driver in a UNIX operating 
system to add a capability to operate in a manner that 
allows the user to issue direct commands to a device 
through the volume management system drivers. 



Description of Related Art- 

In a UNIX operating system there exist volume man- 
agement systems for devices particularly disk drive de- 
vices for managing the storage of information on optical 
or magnetic disk in a storage system. The volume man- 
agement software is part of the kernel in the UNIX op- 
erating system. The objective of this volume manage- 
ment software is to manage the storage media as op- 
posed to management of the storage device. For exam- 
ple, the volume management software would access 
storage media by name such as the volume name for a 
floppy disk in a diskette drive or for cylinders in a hard 
disk drive. Before volume management was available 
a device driver in the UNIX kernel provided direct access 
to a device by the device name as for example, the A 
disk drive or the C disk drive. 

The present design of volume management system 
drivers is referred to as layered. As an example of op- 
erating in a layered volume management system, Fig. 
1 shows a read volume operation. Operation 11 from the 
application program (user) to the operating system ker- 
nel is "read /vol," i.e. a request to read data from a lo- 
cation identified as a storage media volume. The proc- 
ess flows from the read request operation 11 from the 
user to the kernel of the UNIX operating system where 
a device driver at a first layer in the volume management 
system is the block device module "bdev_strategy 
(voLdev)" 12. Device driver 12 at this first layer inter- 
prets the read operation for the volume and identifies 
the type (storage, printer, display, etc.) of device as 
specified by the "(vol_dev)" parameters. The volume pa- 
rameters in this case identify a storage type of device. 
This first driver routine 12 calls module 14,"volstrategy 
(vol_dev) ; M at the next layer. Routine 12 knows that for 
vol_dev parameters received, it needs to call volstrategy 
(vol_dev). Module 14 further interprets vol_dev param- 
eters received from module 1 2 and identifies the storage 
device or storage system where the volume is located. 
The volstrategy module 14 then drives routine 16 back 
up at the device driver layer 1 2. Module 1 4 identifies the 



voLdev number received as actual device number "tp- 
>voldev," so it passes that to the block device driver 
routine 16, "bdev_strategy(tp->voLdev)." Routine 16 
identifies a type of storage device, a hard disk drive, a 
5 floppy disk drive or yet another storage system. In this 
example the device is a floppy disk drive or diskette 
drive. Routine 16 calls module 18 which is the floppy 
disk device driver for the diskette drive where the vol- 
ume is located. Module 18 is the lowest layered level. 
io and in this example module 18 is "fdstrategy(fd_dev),' 
a floppy disk driver routine. 

In this layered volume management system the de- 
vice that is ultimately opened and contains the volume 
being accessed is exclusively opened by the volume 
is management system. Therefore, it is not possible for a 
dir ect access read operation such as "read /device" op- 
era:ion 19 from the user to gain access to a device al- 
ready accessed by the volume management system. 
This is indicated in Fig. 1 by the blocked path between 
20 operation 19 and module 18. 

In the past users were not able to get direct access 
to a device, and were only able to access it through the 
volume management system, but first they had to go 
through a volume check command and then recite a 
2 5 path from the volume down to the device where the in- 
formation in the volume to be accessed was located. 
This level of complexity for the user to be able to access 
a device has prompted many users just to turn off vol- 
ume management and use only device direct access 
30 commands. What is needed is the ability to have the 
UNIX operating system interpret both a volume man- 
agement access command from the user and a direct 
devise access command from the user without conflict. 
Direct access to a device through multiple layers of 
35 drivers is typically referred to in the art as stacked device 
drivers. In stacked device drivers the intermediate driv- 
ers are transparent. Accordingly, the read command 
from she user may proceed down the device driver layer 
and ; nto the storage device driver layer without any vol- 
40 ume path specification by the user. What is needed by 
the user might be referred to as a volume management 
system that is both layered and stacked. 

The following background art relates in general to 
the problem of device or volume access conflicts in a 
45 UNIX environment. 

For example : EP-A-0,432,853 is directed to a vol- 
ume management system in a UNIX environment. More 
particularly, it relates to maintaining a volume group sta- 
tus area to track updates to volumes in a volume group. 
50 However, it does not teach or suggest managing the 
combination of an open volume operative system and 
an open device operative system, as described and 
claimed in the present invention. 

IBM TECHNICAL DISCLOSURE BULLETIN, Vol. 
55 34., No. 10A, March 1, 1992, pages 124-125 discloses 
a "mechanism to allow cascaded device drivers to pass 
along select/poll I/O event requests." 

WO-A-91 19245 includes a description of a process 
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for opening and closing a disk drive device. 

US-A-4,819,159 relates to a fault tolerant system 
building block (SBB) or manager where if there is a fail- 
ure by one such manager in control ("ownership') of a 
disk, then a second SBB takes over control of the disk. 

This background art does not contain a teaching of 
the management of both volume access requests and 
device access requests as described and claimed in the 
present invention. 

Summary of the Invention 

The present invention relates to apparatus end a 
method for managing the access to storage devices by 
user requests to a computing system, in accordance 
with claims 1 and 8, which follow. 

It is an object of this invention to provide a layered 
and stacked volume management system. 

In accordance with this invention, the above object 
is accomplished by a computing system operating a vol- 
ume management system for the storage of information 
and providing to the users of the volume management 
system parallel process paths for accessing a storage 
device as an access volume operation or as an access 
device operation. Further the volume management sys- 
tem prevents the two parallel logical operations from 
conflicting with each other by performing open volume 
operation and open device operation that indirectly com- 
municate by setting and clearing volume data. The vol- 
ume data is meta-data that describes characteristics of 
the volume being accessed and the device being ac- 
cessed. The meta-data includes an open count and an 
exclusive flag to track the open status of a device. Open 
count indicates if the device is open, and the exclusive 
flag indicates whether the storage device has been 
opened exclusively by either the open volume or the 
open device operation request from a user. 

The inventive process includes computer imple- 
mented steps of accessing a storage device through 
parallel processes - access volume process and ac- 
cess device process. The access volume process and 
the access device process both detect whether the re- 
quested storage device is already open and whether or 
not its opened exclusively. This detection is accom- 
plished by testing for an exclusive flag in the volume da- 
ta for the device the user requested access to. Nexr the 
access volume process and the access device process 
test whether the request is an exclusive open request. 
These tests allow the parallel processes to maintain an 
open count and an exclusive flag for each storage de- 
vice. By monitoring the open count for non-zero and the 
exclusive flag, each process can return a busy code 
when the requested device is already exclusively open 
or the request is for an exclusive open, and the device 
has already been opened by a previous request that is 
still pending, i.e. has not been closed. 

The great advantage of this invention is that it per- 
mits a user to access storage devices either through an 



access volume operation or an access device operation. 
To the user either process is equally available and thus 
the user can operate both processes in parallel without 
concern for disabling or inhibiting the volume manage- 

5 ment system. 

The foregoing and other objects, features and ad- 
vantages of the invention will be apparent from the fol- 
lowing moreparticulardescription of a preferred embod- 
iment of the invention as illustrated in the accompany 

io drawings. 

Brief Description of Drawings 

Fig. 1 is a flow diagram of the layered volume man- 
*5 agement system as it exists in the prior art. 

Fig. 2 is a flow diagram of a preferred embodiment 
of the invention, implementing both the layered and 
stacked volume management system to perform a read 
operation. 

20 Fig. 3 illustrates a computing system to perform the 
computer implemented steps in accordance with the in- 
vention. 

Fig. 4 shows a preferred embodiment for the open 
volume and open device processes and logical opera- 
25 tions of the invention. 

Fig. 5 shows the structure of the volume data indi- 
• eating the open count and exclusive flag in the meta data 
making up the volume data. 

Fig. 6 shows the detailed operation flow of the vol- 
20 ume open process in Fig. 4. 

Fig. 7 shows the detailed operation flow of the de- 
vice open process in Fig. 4. 

Fig. 8 shows a preferred embodiment of the volume 
close and device close processes in accordance with 
25 the invention. 

Detailed Description of Preferred Embodiments 

The volume management system operations in- 

*o volve four primary operations - open, read, write, and 
close. Each of these operations follow the parallel flow 
through layers of driver modules. In one process path, 
the layers are access volume process defined. In the 
other process path, the layers are access device proc- 

^5 ess defined The parallel process paths for read and 
write operations are independent process flows. How- 
ever, the parallel process paths for the open operation 
and the close operation must interact to deal with ac- 
cesses that require exclusive use of the device. 

50 As shown in Fig. 2, a preferred embodiment of the 
layered and stacked volume management system for 
the read operation is initiated by the user through either 
a read from volume operation 20 or a read from device 
operation 22. The read from volume operation 20 re- 

55 quest is passed to the device driver "bdev_strategy 
(vol_dev)' module 24. In turn, the block device strategy 
module 24 calls a volume strategy module 26 based on 
the type of device identified in the voLdev parameters. 
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The volume strategy driver 26 calls a device driver 
30 based on the device identified by the voLdev. Block 
device strategy module 30 then calls the actual device 
strategy driver, which in this case is a floppy disk device 
driver module 32. 

In the process flow for the read from device opera- 
tion 22 from the user, operation 22 calls the block device 
strategy module 34 for a floppy disk device. This driver 
module 34 then drives a volume strategy driver module 
28 which calls the floppy disk strategy device driver 
module 32. In this way, the layered process 24, 26 : 30 
and stacked process 34, 28 for the volume management 
system operate in parallel. The write operation flow is 
identical to the read operation flow. 

The operating environment in which the present in- 
vention is used encompasses the general distributed 
computing system, wherein general purpose comput- 
ers, workstations, or personal computers are connected 
via communication links of various types, in a client- 
server arrangement, wherein programs and data, many 
in the form of objects, are made available by various 
members of the system/Some of the elements of a gen- 
eral purpose workstation computer are shown in Fig. 3, 
wherein a processor 1 is shown, having an input/output 
(I/O) section 2, a central processing unit (CPU) 3 and a 
memory section 4. The I/O section 2 is connected to a 
keyboard 5, a display unit 6, a disk storage unit 9 and a 
CD-ROM drive unit 7. The CD-ROM unit 7 can read a 
CD-ROM medium 8 which typically contains programs 
10 and data. The computer program products contain- 
ing mechanisms to effectuate the apparatus and meth- 
ods of the present invention may reside in the memory 
section 4, or on a disk storage unit 9, or on the CD-ROM 
8 of such a system. Examples of such systems include 
SPARC systems offered by Sun Microsystems, Inc., 
personal computers offered by IBM Corporation and by 
other manufacturers of IBM-compatible personal com- 
puters, and systems running the UNIX operating sys- 
tem. 

Before an access (read or write) operation may be 
performed as described above with reference to Fig. 2 
possible conflicts in access to the same storage device 
by either the read from volume operation 20 or the read 
from device operation 22 must be resolved by an open 
operation. The open operation as shown in Fig. 4 begins 
with either a user open volume request operation 36 of 
"open of device in /vol" or a user open device request 
operation 38 of "open of device in /dev." The volume 
open operation calls the B dev_open(voLpath) M driver 
module 40. Dev_open Module 40 determines the device 
to be opened from the vol_path parameters and calls 
the Volopen(voLpath)" driver module 42. Volopen mod- 
ule 42 tests for exclusive open status and tests for an 
exclusive open request received from the user's open 
volume operation 36. Volopen module 42 operates on • 
the volume data 44 assigned to the device requested by 
the open request. Volopen module determines from the 
volume data if there are conflicts in open requests from 



open volume operation 36 and from open device oper- 
ation 38. 

In Fig. 4 the open requests from open device oper- 
ation 38 pass through "dev_open(fd__path)" driver mod- 

5 ule 46 to "vol_st_open(fd_path)' driver module 48. 
Dev_open Module 46 determines the device to be 
opened from the fd_path parameters and calls the 
"vol_st_open(fd_path)" driver module 48. Vol_st_open 
module 48 just like volopen module 42 operates on the 

io volume data 44 to resolve conflicts in open requests 
from open volume operation 36 and from open device 
operation 38. 

The structure of the volume data 44 is illustrated in 
Fig. 5 and the operation flow of volopen module 42 and 

5 vol_st_open module 48 are shown in Figures 6 and 7, 
respectively. In Fig. 5, the volume data 44 structure is 
shown expanded as storage areas 44a. The volume da- 
ta comprises meta data that describes characteristics of 
the volume and device where the volume is located. The 

0 characteristics of interest to the preferred embodiment 
of the invention are open count 50 and exclusive flag 
52. These characteristics are used by volopen module 
42 and vol_st_open module 48 to resolve conflicts in ac- 
cess to a device. 

5 In Fig. 6, the volopen process and logic operations 
for resolving conflicts are shown. When the volopen 
module is called, operation 53 reads the volume data 
characteristics from the volume meta-data for the re- 
quested device. Decision operation 54 first tests the vol- 

? ume data 44 for an exclusive flag for the device. If there 
is an exclusive flag, the process branches to operation 
56, and operation 56 returns an EBUSY code to the vol- 
ume management system. The volume management 
would then process, the next user operation request. If 

> there is no exclusive flag set for the requested device, 
the process branches to decision operation 58. 

Decision operation 58 detects whether the volume 
open request from the user is an exclusive open re- 
quest. If the open request is not exclusive, the process 

1 branches to increment operation 60 to increase the 
open count in the volume data by one. Operation 61 
grants the open request, and a return success code 
goes to the operating system. 

If the open request is exclusive, the processes 
branches YES from decision operation 58 to decision 
operation 62. Operation 62 tests whether the open count 
in the volume data characteristics is non-zero. If there 
is any count in the open count characteristic, operation 
64 returns an EBUSY code to the volume management 
system. In this situation, the device is already open, so 
an exclusive open is not possible at this time. If the open 
count is zero, the process branches NO from decision 
operation 62 to set operation 66. Operation 66 sets the 
exclusive flag in the volume data for the requested de- 
vice. Operation 60 then increments the open count char- 
ade ristic, operation 61 grants the open request, and the 
volopen module operation for volume access process is 
complete. 
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If the user request was an open device request, the 
process or logical operations are performed by 
vol_st_open module as shown in Fig. 7. When the 
vol_st_open module is called, operation 67 reads the 
volume data characteristics for the volume data as- 
signed to the requested device. Decision operation 68 
detects whether the volume data 44 contains an exclu- 
sive flag for the device. If there is an exclusive flag, the 
process branches YES to return operation 70. Opera- 
tion 70 returns an EBUSY code to the volume manage- 
ment system. If there is no exclusive flag set for the re- 
quested device, the process branches to decision oper- 
ation 72. 

Decision operation 72 tests if the device open re- 
quest from the user is an exclusive open request. If the 
open request is not exclusive, the process branches to 
increment operation 74 to increase the open count in 
the volume data by one. Operation 75 grants the open 
request, and a success code is returned to the operating 
system. 

If the open request is exclusive, decision operation 
72 branches the process to decision operation 76. Op- 
eration 76 detects whether the open count in the volume 
data characteristics is non-zero. If there is a count in the 
open count characteristic for the device in the volume 
data, the process branches to operation 78 which re- 
turns an EBUSY code to the volume management sys- 
tem. If the open count is zero, the process branches NO 
from decision operation 76 to set exclusive flag opera- 
tion 80. Operation 80 sets the exclusive flag for the re- 
quested device in the volume data, and the process 
flows to "clone me" operation 82. 

Clone me operation 82 changes the identification of 
the device to the host using system. This causes the 
using system to set another open count characteristic 
for the device even though the device being accessed 
is unchanged. The purpose of this cloning operation 
which sets a new open count characteristic is to create 
the appearance of a new device open count for each 
open device request from the user. In the UNIX operat- 
ing system, open device operations from the using sys- 
tem are sent for each open request. However if there 
are multiple accesses to the same device, the operating 
system only sends a close request once at the end of 
all the open operations, i.e. at the conclusion of the last 
access operation. Accordingly the volume management 
system when dealing with open device operations must 
have a mechanism to balance open requests and close 
requests. This is accomplished by the cloning operation 
82 which creates a pseudo device identity and thus vol- 
ume data for each open device request so that the op- 
erating system will send a close device request for each 
open device request when each access is completed. 
After the cloning operation 82, operation 74 increments 
the new open count characteristic for the pseudo device 
to one, and the vol_st_open operation is complete. 

When the read or write access is completed for the 
requested volume or device, close operations are sent 
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by the user to the kernel of the UNIX operating system. 
The close operation is the same as the open operation 
as illustrated in Fig. 4 except the drive modules are close 
modules. Also, the volclose(vol_path) operation and 
5 voLst_close(fd_path) are much simpler than volopen 
(vol_path) operation and the vol_st_open(fd _path) op- 
eration. 

As illustrated in Fig. 6, the volclose operation and 
vol_st_close operation are identical. These processes 

10 only have to reset the open count characteristic and the 
exclusive flag characteristic of the volume data for the 
requested device. When either volclose or vol_st_close 
are called, the process clears the open count in opera- 
tion 84 and clears the exclusive flag in operation 86. The 

is volume management system is now ready to process 
further access requests to the device from user either 
by the volume access process or the device access 
process. 

20 

Claims 

1 . In a computing system, apparatus for managing the 
access to storage devices by user requests (36, 38) 
25 to the computing system, said apparatus compris- 
ing: 

volume data (44) for each storage device 
stored in the computing system, said volume 

30 data including characteristics indicating the 

open status of each storage device; 
an open volume operative system (40) and an 
open device operative system (46) exchanging 
open status information for a storage device re- 

35 quested by a user through the volume data (44) 

for the requested storage device (32); 
said open volume operative system (40) re- 
sponsive to the volume data characteristics for 
testing whether the requested device is already 

40 open exclusively and whether the open volume 

request (36) from the user application is an ex- 
clusive open request; 

said open device operative system (46) respon- 
sive to the volume data characteristics for test- 
es ing whether the requested device is already 
open exclusively and whether the open device 
request (38) from the user application is an ex- 
clusive open request; 

said open volume operative system and said 
so open device operative system return an open 

operation (42, 48) successful to permit read or 
write access to the device by the computing 
system when each operative system detects 
that the requested device is not already exclu- 
55 sively open or if the request is an exclusive 

open request that the device is not already 
open. 
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2. The apparatus of claim 1 , and in addition: 



said open volume operative system and said 
open device operative system return a busy 
code (56) to the computing system when the 
requested storage device is already exclusively 
open (54) or when the requested storage de- 
vice is already open and the request is for an 
exclusive open (58) of the storage device. 

3. The apparatus of claim 1 or claim 2, wherein said 
volume data (44) includes an open indicator (50) 
and an exclusive open indicator (52) or exclusive 
flag for each storage device. 

4. The apparatus of claim 3, wherein the open indica- 
tor is an open count (60) incremented for each open 
request and wherein: 

said open volume operative system (40) and 
said open device operative system (46) test for 
a non-zero count (52) to determine whether the 
requested storage device is already open. 

5. The apparatus of claim 1 s wherein the characteris- 
tics in the volume data for each storage device in- 
clude an open count (50) indicating whether the 
storage device is open and an exclusive flag (52) 
indicating (54) whether the storage device is exclu- 
sively open. 

6. The apparatus of claim 5 wherein: 

each of said open volume operative system and 
said open device operative system detect (62) 
a zero open count and a request for an exclu- 
sive open, and grant (61) the request, and set 
(66) an exclusive flag in the volume data for the 
requested storage device. 
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7. The apparatus of claim 6 wherein: 

each of said open volume operative system and 
said open device operative system detect a 
nonexclusive open request, grant the request, 
and increment (60) the open count for the re- 
quested storage device. 

8. A method for managing access to storage devices 
by user requests to a computing system comprising 
the steps of: 

storing a volume data (44) characteristic list for 
each storage device, the characteristic list indi- 
cating the open status of each storage device: 
in response to an open volume request (36) or 
an open device request (38), detecting (54) 
from the characteristic list whether the request- 
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ed device is already exclusively open; and 
in response to an open volume request or an 
open device request, detecting (58) whether a 
request for a storage device is an exclusive 
open request and testing (62) the characteristic 
list to detect if the requested device is already 
open, whereby the availability of the storage 
device is determined. 

The method of claim 8, and in addition the steps of: 

returning to the computing system a busy code 
(56) if the requested device is already exclu- 
sively open; and 

returning a busy code (64) to the computing 
system if the request is an exclusive open re- 
quest and the requested device is already 
open. 



10. The method of claim 8 or claim 9, wherein the char- 
acteristic list includes an open count indicating the 
number of current open requests to each device 
and includes an exclusive flag indicating whether or 
not the device has been opened exclusively by a 
request. 

11. The method of claim 1 0, and in addition the steps of: 

granting (61) an exclusive open request and 
setting the exclusive flag in the requested char- 
acteristic list if the requested device is not al- 
ready open; and 

setting the open count to non-zero in the re- 
quested characteristic list if the open volume 
request or the open device request is granted, 
whereby the access to a storage device may 
be requested either as a volume request or a 
device request and conflicts between the re- 
quests are managed. 



Patentanspruche 

1 . Vorrichtung in einem Computersystem fur das Ma- 
nagement des Zugriffs auf Speichergerate durch 
Benutzeranforderungen (36, 38) an das Computer- 
system, wobei die Vorrichtung enthalt: 

Datentragerdaten (44) fur jedesSpeichergerat, 
die in dem Computersystem gespeichert sind 
und Eigenschaften umfassen, die den geoffne- 
ten Status jedes Speichergerats angeben; 
ein Datentrageroffnung-Ausfuhrungssystem 
(40) und ein Geratoffnung-Ausfuhrungssystem 
(46), die Informationen bezuglich des geoffne- 
ten Status fur ein Speichergerat, das von einem 
Benutzer angefordert wird, anhand der Daten- 
tragerdaten (44) fur das angeforderte Spei- 
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chergerat (32) austauschen; 
wobei das Datentrageroffnung-Ausfuhrungs- 
system (40) auf die Datentragerdaten-Eigen- 
schaften anspricht, um zu prufen, ob das ange- 
forderte Gerat bereits exklusiv geoffnet ist und $ 
ob die Datentrageroffnung-Anforderung (36) 
von der Benutzeranwendung eine exklusive 
Offnungsanforderung ist; 
wobei das Geratoffnung-Ausfuhrungssystem 
(46) auf die Datentragerdaten-Eigenschaften *o 
anspricht, um zu prufen, ob das angeforderte 
Gerat bereits exklusiv geoffnet ist und ob die 
Geratoffnung-Anforderung (38) von der Benut- 
zeranwendung eine exklusive Offnungsanfor- 
derung ist; is 
wobei das Datentrageroffnung-Ausfuhrungs- 
system und das Geratoffnung-Ausfuhrungssy- 
stem eine Offnungsoperation (42, 48) zuruck- 
leiten, die erfolgreich einen Leseoder Schreib- 
zugriff auf das Gerat durch das Computersy- 20 
stem ermoglicht, wenn jedes Ausfuhrungssy- 
stem erfaGt, daB das angeforderte Gerat nicht 
bereits ausschlieGlich geoffnet ist oder, falls die 
Anforderung eine exklusive Offnungsanforde- 
rung ist, daf3 das Gerat nicht bereits geoffnet 25 
ist. 

2. Vorrichtung nach Anspruch 1, wobei weiterhin: 

das Datentrageroffnung-Ausfuhrungssystem 30 
und das Geratoffnung-Ausfuhrungssystem an 
das Computersystem einen Belegtcode (56) 
zuruckleiten, wenn das angeforderte Speicher- 
gerat bereits exklusiv geoffnet ist (54) oder 
wenn das angeforderte Speichergerat bereits 35 
geoffnet ist und die Anforderung auf ein exklu- 
sives Offnen (58) des Speichergerats zielt. 

3. Vorrichtung nach Anspruch 1 oder 2, wobei die Da- 
tentragerdaten (44) einen Offnungsanzeiger (50) *o 
und einen Exklusivoffnungsanzeiger (52) oder ei- 
nen Exklusivmerker fur jedes Speichergerat enthal- 
ten. 

4. Vorrichtung nach Anspruch 3, wobei der Offnungs- 45 
anzeiger ein Offnungszahlstand (60) ist, der bei je- 
der Offnungsanforderung inkrementiert wird, und 
wobei: 

das Datentrageroffnung-Ausfuhrungssystem 50 
(40) und das Geratoffnung-Ausfuhrungssy- 
stem (46) auf einen von null verschiedenen 
Zahlstand (62) prufen, um zu bestimmen, ob 
das angeforderte Speichergerat bereits geoff- 
net ist. 55 

5. Vorrichtung nach Anspruch 1, wobei die Eigen- 
schaften in den Datentragerdaten fur jedes Spei- 



chergerat einen Offnungszahler (50), der angibt, ob 
das Speichergerat geoffnet ist, sowie einen Exklu- 
sivmerker (52), der angibt (54), ob das Speicherge- 
rat exklusiv geoffnet ist, enthalten. 

6. Vorrichtung nach Anspruch 5, wobei: 

sowohl das Datentrageroffnung-Ausf Oh rungs - 
system als auch das Geratoffnung-Ausfuh- 
rungssystem einen Null-Offnungszahlstand 
und eine Anforderung fur ein exklusives Offnen 
erfassen (62), die Anforderung gewahren und 
in den Datentragerdaten fur das angeforderte 
Speichergerat einen Exklusivmerker setzen 
(66). 

7. Vorrichtung nach Anspruch 6, wobei: 

sowohl das Datentrageroffnung-Ausfuhrungs- 
system als auch das Geratoffnung-Ausfuh- 
rungssystem eine nicht exklusive Offnungsan- 
forderung erfassen, die Anforderung gewahren 
und den Offnungszahlstand fur das angefor- 
derte Speichergerat inkrementieren (60). 

8. Verfahren fur das Management des Zugriffs auf- 
Speichergerate durch Benutzeranforderungen an 
ein Computersystem, mit den folgenden Schritten: 

Speichern einer Eigenschaftsliste von Daten- 
tragerdaten (44) fur jedes Speichergerat, wobei 
die Eigenschaftsliste den geoffneten Status je- 
des Speichergerats angibt; 
als Antwort auf eine Datentrageroffnung-Anfor- 
derung (36) oder eine Geratoffnung-Anforde- 
rung (38) Erfassen (54), ob das angeforderte 
Gerat bereits exklusiv geoffnet ist, anhand der 
Eigenschaftsliste; und 

als Antwort auf eine Datentrageroffnung-Anfor- 
derung oder eine Geratoffnung-Anforderung 
Erfassen (5B), ob eine Anforderung fur ein 
Speichergerat eine exklusive Offnungsanfor- 
derung ist, und Prufen (62) der Eigenschaftsli- 
ste, um zu erfassen, ob das angeforderte Gerat 
bereits geoffnet ist, wobei die Verf ugbarkeit des 
Speichergerats bestimmt wird. 

9. Verfahren nach Anspruch 8, weiterhin mit den fol- 
genden Schritten: 

Zuruckleiten eines Belegtcodes (56) an das 
Computersystem, falls das angeforderte Gerat 
bereits exklusiv geoffnet ist; und 
Zuruckleiten eines Belegtcodes (56) an das 
Computersystem, falls die Anforderung eine 
Exklusivoffnungsanforderung ist und das ange- 
forderte Gerat bereits geoffnet ist. 
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10. Verfahrennach Anspruch 8oder Anspruch 9, wobei 
die Eigenschaftslisteeinen Offnungszahlstand, der 
die Anzahl momentaner Offnungsanforderungen 
fur jedes Gerat angibt, und einen Exklusivmerker, 
der angibt, ob das Gerat durch eine Anforderung 
exklusiv geoffnet worden ist, enthalt. 

11. Verfahren nach Anspruch 10, weiterhin mil denfol- 
genden Schritten: 

Gewahren (61 ) einer Exklusivoffnungsanforde- 
rung und Setzen des Exklusivmerkers in der 
angeforderten Eigenschaftsliste, falls das an- 
geforderte Gerat nicht bereits geoffnet ist; und 
Setzen des Offnungszahlers auf Nichtnull in 
der angeforderten Eigenschaftsliste, falls die 
Datentrageroffnung-Anforderung oder die Ge- 
ratoffnung-Anforderung gewahrt wird, wobei 
der Zugriff auf ein Speichergerat entweder als 
Datentrageranforderung oder als Geratanfor- 
derung angefordert werden kann und Konflikte 
zwischen den Anforderungen gemanagt wer- 
den 
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Revendications 

1 . Dispositif, faisant partie d'un systeme informatique, 
destine a gerer I'acces a des dispositifs de memoire 
par des demandes d'utiiisateurs (36, 38) adressees 
au systeme informatique, ledit dispositif compre- 
nant: 

des donnees de volume (44) pour chaque dis- 
positif de memoire, memorisees dans le syste- 
me informatique, lesdites donnees de volume 
comprenant des caracteristiques indiquant 
I'etat ouvert de chaque dispositif de memoire; 
un systeme (40) operationnel d'ouverture de 
volume et un systeme (46) operationnel 
d'ouverture de dispositif echangeant une infor- 
mation d'etat d'ouverture pour un dispositif de 
memoire demande par un utilisateur par I'inter- 
mediaire des donnees de volume (44) pour le 
dispositif de memoire requis (32); 
ledit systeme operationnel d'ouverture de volu- 
me (40) reagissant aux caracteristiques de 
donnees de volume pour verifier si le dispositif 
demande est deja ouvert de maniere exclusive 
et si la demande d'ouverture de volume (38) 
provenant de I'application d'utilisateur est une 
demande d'ouverture exclusive; 
ledit systeme operationnel d'ouverture de dis- 
positif (46) reagissant aux caracteristiques de 
donnees de volume pour verifier si le dispositf 
demande est deja ouvert de maniere exclusive 
et si la demande d'ouverture de dispositif (38) 
provenant de I'application d'utilisateur est une 
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demande d'ouverture exclusive; 
ledit systeme operationnel d'ouverture de volu- 
me et ledit systeme operationnel d'ouverture de 
dispositif renvoient une operation d'ouverture 
(42, 48) reussie pour permettre I'acces en lec- 
ture ou en ecriture au dispositif par le systeme 
informatique lorsque chaque systeme opera- 
tionnel detecte que le dispositif demande n'est 
pas deja ouvert de maniere exclusive ou, si la 
demande est une demande d'ouverture exclu- 
sive, que le dispositif n'est pas deja ouvert. 

Dispositif selon la revendication 1, dans lequel, en 
outre: 

ledit systeme operationnel d'ouverture de volu- 
me et ledit systeme operationnel d'ouverture de 
dispositif renvoient un code d'occupation (56) 
au systeme informatique lorsque le dispositif de 
memoire demande est deja ouvert de maniere 
exclusive (54) ou lorsque le dispositif de me- 
moire demande est d6ja ouvert et que la de- 
mande se rapporte a une ouverture exclusive 
(58) du dispositif de memoire. 

Dispositif selon la revendication 1 ou la revendica- 
tion 2, dans lequel lesdites donnees de volume (44) 
comprennent un indicateur d'ouverture (50) et un 
indicateur d'ouverture exclusive (52), ou indicateur 
exclusif, pour chaque dispositif de memoire. 

Dispositif selon la revendication 3, dans lequel Tin- 
dicateur d'ouverture est un compteur d'ouverture 
(60) increments a chaque demande d'ouverture et 
dans lequel ; 

ledit systeme operationnel d'ouverture de volu- 
me (40) et ledit systeme operationnel d'ouver- 
ture de dispositif (46) verifient la presence 
d'une valeur non nulle (62) afin de determiner 
si le dispositif de memoire demande est deja 
ouvert. 

Dispositif selon la revendication 1, dans lequel les 
caracteristiques dans les donnees de volume pour 
chaque dispositif de memoire comprennent un 
compteur d'ouverture (50) indiquant si le dispositif 
de memoire est ouvert et un indicateur exclusif (52) 
indiquant (54) si le dispositif de memoire est ouvert 
de maniere exclusive. 

Dispositif selon ia revendication 5, dans lequel: 

chacun dudit systeme operationnel d'ouverture 
de volume et dudit systeme operationnel 
d'ouverture de dispositif detecte (62) un nom- 
bre d'ouverture nul et une demande d'ouverture 
exclusive, et accepte (61) la demande, et posi- 
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tionne (66) un indicateur exclusif dans les don- 
nees de volume pour le dispositif de memoire 
demande. 

7. Dispositif selon la revendication 6, dans lequel: 5 

chacun dudit systeme operationnel d'ouverture 
de volume et dudit systeme operationnel 
d'ouverture de dispositif detecte une demande 
d'ouverture non exclusive, accepte la deman- io 
de, et incremente (60) le compteur d'ouverture 
pour le dispositif de memoire demande. 

8. Procede de gestion d'acces a des dispositifs de me- 
moire par des demandes d'utilisateur a un systeme is 
informatique comprenant les etapes de: 

memorisation d'une liste caracteristique de 
donn6es de volume (44) pour chaque dispositif 
de memoire, la liste caracteristique indiquant 20 
I'etat d'ouverture de chaque dispositif de me- 
moire; 

en reponse a une demande d'ouverture de vo- 
lume (36) ou une demande d'ouverture de dis- 
positif (38), detection (54), a partir de la liste 25 
caracteristique, du fait que le dispositif deman- 
de est deja ouvert de maniere exclusive; et 
en reponse a une demande d'ouverture de vo- 
lume ou une demande d'ouverture de dispositif, 
detection (58) du fait que la demande pour un 30 
dispostif de memoire est une demande 
d'ouverture exclusive et verification (62) de la 
liste caracteristique afin de detecter si le dispo- 
sitif demande est deja ouvert, de sorte que la 
disponibilite" du dispositif de memoire est deter- 35 
minee. 

9. Procede selon la revendication 8, comprenant, en 
outre, les etapes de: 

40 

renvoi, vers le systeme informatique, d'un code 
d'occupation (56) si le dispositif demande est 
deja ouvert de maniere exclusive; et 
renvoi d'un code d'occupation (64) vers le sy- 
teme informatique si la demande est une de- 45 
mande d'ouverture exclusive et que le dispositif 
demande est deja ouvert. 

10. Precede selon la revendication 8 ou la revendica- 
tion 9, dans lequel la liste caracteristique comprend so 
un compteur d'ouverture indiquant le nombre de de- 
mandes d'ouvertures courantes pour chaque dispo- 
sitif et comprend un indicateur exclusif indiquant si 

le dispositif a 6t6 ouvert de maniere exclusive ou 
non par une demande. s$ 

11. Proced§ selon la revendication 10, et comprenant, 
en outre, les etapes de: 



acceptation (61) d'une demande d'ouverture 
exclusive et positionnemeni de I'indicateur ex- 
clusif dans la liste caracteristique demandee si 
le dispositif demande n'est pas deja ouvert; et 
positionnemeni du compteur d'ouverture a une 
valeur non nulle dans la liste caracteristique de- 
mandee si la demande d'ouverture de volume 
ou la demande d'ouverture de dispositif est ac- 
cepted, de sorte que faeces a un dispositif de 
memoire peut etre demande soit comme une 
demande de volume soit comme une demande 
de dispositif et les conflits enire les demandes 
sont geres. 
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